Product Backlog
The product backlog is a prioritized list of requirements that the customer wants, described using the customer's terminology. These are called //stories//, or sometimes just //backlog items//. It is owned by the product owner. Story Fields A product backlog can include the following fields, applicable to most projects: * ID: A unique identification, just an auto-incremented number. This is to avoid losing track of stories when we rename them. * Name: A short, descriptvie name of the story. For example "See your own transaction history". Clear enough so that developers and the product owner understand approximately what we are talking about, and clear enough to distinguish it from other stories. Normally 2-10 words. * Importance: The product owner's importance rating for this story. For example 10. Or 150. High = more important. Avoid the term "priority" since priority 1 is typically considered the "highest" priority. * Initial estimate: The team's initial assessment of how much work is needed to implement this story compared to other stories. The unit is story points and usually corresponds roughly to "ideal man-days". The points should be based only on actual work. * How to demo: A high-level description of how this story will be demonstrated at the sprint demo. This is essentially a simple test specification. "Do this, then do that, then this should happen". ** If you practice TDD this description can be used as pseudo-code for your acceptance test code. * Notes: Any other info, clarifications, refreences to other sources of info, etc. Normally very brief. This is best done in a spreadsheet shared with all involved parties. Don't place it under version control as a shared drive turns out to be the simplest way to allow multiple simulatneous editors without causing lock or merge conflicts. Almost all other artifacts, however, are placed under verison control. Additional story fields Sometimes the product backlog can have additional fields, mostly as a convenience for the product owner to help him sort out his priorities: * **Track:** A rough categorization of this story, e.g. "back office" or "optimization". This is mainly used for filtering information. * **Components:** Usually realized as checkboxes, e.g. "database, server, client". The team or product owner can identify which technical components will be involved in implmenting this story. This is useful when there are several teams and want to make it easier for each team to decide which stories to take on. * **Requestor:** The product owner may want to keep track of which customer or stakeholder originally requested the item, in order to give him feedback on the progress. * **Bug tracking ID:** If you have a seperate bug tracking system it is useful to keep track of any direct correspondence between a story and one or more reported bugs. Keep the Product Backlog at a Business Level The team is normally better suited to figure out //how// to solve something, so the product owner should focus on business goals. Don't: "Add indexes to the Events table".\\ Do: "Speed up the search event form in the back office". Technically oriented stories should be analyzed to find the underlying goal. Then they should be rephrased in terms of the underlying goal. The original technical description ends up as a note. References - Scrum and XP from the Trenches, Ch. 2 Category:Scrum